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ABSTRACT 

Wearable  ubiquitous  computing  devices  are  often  size-  and 
power-constrained,  which  prevents  them  from  directly  con¬ 
necting  to  the  Internet.  A  common  pattern  is  therefore  to 
interpose  a  smart  phone  as  a  router  and  to  deliver  graphical 
user  interfaces  for  such  hardware.  However,  implementing 
the  entire  pipeline  from  embedded  device  through  a  phone 
to  the  Internet  and  back  requires  a  disjoint  set  of  languages 
and  APIs  accessible  only  to  experts.  In  this  paper,  we  present 
fabryq,  a  new  platform  that  handles  the  complexities  of  creat¬ 
ing  such  applications,  fabryq  is  especially  aimed  at  support¬ 
ing  field  deployments  of  prototype  ubicomp  hardware,  e.g., 
for  new  interactive  health  devices,  fabryq  turns  a  smartphone 
into  a  bridge  that  connects  the  short  range  wireless  technol¬ 
ogy  of  Bluetooth  Low  Energy  (BLE)  with  our  cloud  service 
via  the  Internet.  We  introduce  a  protocol  proxy  programming 
model  to  find  and  control  peripheral  devices  from  Javascript; 
and  describe  a  UI  pushdown  technique  to  render  user  inter¬ 
faces  on  phones  within  reach  of  peripheral  devices.  To  illus¬ 
trate  the  utility  of  our  platform,  we  also  implement  qfabryq, 
a  breadboard  prototyping  platform  similar  to  Arduino  with 
functionality  exposed  over  a  JavaScript  API  built  exclusively 
with  fabryq. 

Author  Keywords 

Toolkits;  ubiquitous  computing;  swarm  devices;  prototyping. 

ACM  Classification  Keywords 

Human-centered  computing-  User  interface  toolkits 

INTRODUCTION 

In  the  predominant  vision  of  ubiquitous  computing,  all  kinds 
of  devices,  from  large  to  small,  become  smart  and  networked. 
One  important  class  of  ubiquitous  computing  devices  are 
small,  wearable  sensors  —  for  example  those  used  in  med¬ 
ical  and  fitness  applications.  Unfortunately,  these  cannot  just 
be  connected  to  the  Internet  (e.g.,  via  WiFi)  because  of  size 


and  power  constraints.  In  practice,  therefore,  wearable  ubi¬ 
comp  devices  are  often  constructed  using  a  three-level  archi¬ 
tecture  consisting  of:  1)  a  very  energy  efficient,  embedded 
low  power  device  with  a  short  range  radio;  2)  a  user’s  mobile 
phone,  which  shows  a  user  interface  but  also  acts  as  a  router 
from  body- area  networks  to  the  Internet;  3)  server  code  for 
aggregating  data  and  reasoning  across  multiple  users  and  de¬ 
vices.  We  refer  to  this  such  applications  as  MPC  (eMbedded- 
Phone-Cloud)  apps  (see  Figure  1).  For  example,  the  FitBit 
fitness  tracking  device  monitors  a  user’s  motions  and  period¬ 
ically  relays  information  to  a  companion  application  running 
on  the  user’s  mobile  phone  (or  PC),  which  in  turn  communi¬ 
cates  with  servers  that  the  FitBit  company  maintains.  Build¬ 
ing  and  maintaining  such  multi-language,  multi-platform  dis¬ 
tributed  systems  is  complex,  error-prone,  and  requires  skills 
in  several  diverse  fields.  Thus,  experimentation  in  deploy¬ 
able,  mobile  wearable  devices  is  largely  reserved  to  experts, 
and  implementation  cycles  are  long  and  complex,  which  pro¬ 
hibits  rapid  prototyping.  While  research  has  introduced  pro¬ 
totyping  toolkits  that  significantly  increase  the  speed  of  de¬ 
sign  explorations  [9,  8,  18],  these  toolkits  often  make  power 
or  connectivity  tradeoffs  that  restrict  their  use  to  lab  settings 
or  stationary,  plug-in  products. 

In  response  to  these  issues,  we  introduce  fabryq,  a  framework 
that  facilitates  the  creation  of  new  wearable  Ubicomp  devices 
by  handling  the  complexities  of  creating  new  mobile  device, 
server,  and  networking  code.  Specifically,  fabryq  takes  the 
form  of  a  mobile  application  and  cloud  service.  The  mobile 
application  turns  an  ordinary  smartphone  into  a  bridge  that 
connects  the  short  range  wireless  technology  of  Bluetooth 
Low  Energy  (BLE)  with  our  cloud  service  via  the  Internet. 
We  chose  BLE  because  it  is  the  single  short  range  wireless 
technology  that  is  ubiquitously  available  on  modem  smart 
phones  and  can  thus  be  widely  employed,  fabryq  applications 
are  written  in  Javascript  and  run  in  a  web  browser,  fabryq  in¬ 
troduces  a  protocol  proxy  programming  model  —  developers 
write  BLE  protocol  calls  in  Javascript  as  if  the  target  device 
were  locally  connected  and  always  available.  The  fabryq  ar¬ 
chitecture  then  finds  a  mobile  phone  within  radio  reach  of  the 
target  BLE  device;  passes  the  command(s)  through  the  phone 
to  the  target  device,  and  returns  data  to  a  the  web  application. 
This  allows  the  creators  of  new  devices  to  focus  on  writing 
the  devices’  firmware  and  creating  new  applications  with  the 
data  from  the  devices,  rather  than  writing  complex  and  error- 
prone  networking  code  (see  Figure  2). 
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Figure  1.  An  example  MPC  application  distributes  logic  and  user  inter¬ 
action  across  embedded  device,  mobile  phone  and  a  cloud  server. 
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Figure  2.  With  fabryq,  developers  use  off-the-shelf  bluetooth  devices  or 
write  firmware  that  exposes  devices’  inputs  and  outputs  over  Bluetooth; 
and  high-level  application  logic  in  Javascript.  The  fabryq  framework 
manages  finding  the  desired  hardware  device  and  a  mobile  phone  within 
range,  and  handles  all  message  marshaling. 


Our  approach  deals  gracefully  with  situations  where  a  BLE 
device  may  move  into  and  out  of  the  range  of  a  mobile  client 
device.  The  star  network  topology  of  BLE  guarantees  de¬ 
terministic  execution  of  commands  in  the  correct  order,  fab¬ 
ryq  handles  the  connection  management  and  networking  that 
make  this  abstraction  possible  in  the  background.  User  in¬ 
terfaces  for  fabryq  applications  such  as  visualizations  of  col¬ 
lected  data  are  also  authored  in  JavaScript,  and  they  can  be 
shown  either  on  the  web,  or  inside  the  fabryq  application  on  a 
mobile  device.  For  this  purpose,  fabryq  introduces  a  UI push¬ 
down  model  where  embedded  data  updates  on  the  server  can 
trigger  the  display  of  interfaces  on  the  phone  that  was  respon¬ 
sible  for  collecting  the  data. 

fabryq  makes  it  easier  for  developers  to  work  with  both  ex¬ 
isting  off  the  shelf  BLE  devices  and  custom  devices  of  their 
own  design.  To  illustrate  fabryq’s  ability  to  interface  with 
off-the-shelf  devices,  we  demonstrate  a  heart  rate  visualiza¬ 
tion  application  from  an  off-the-shelf  BLE  heart  rate  monitor. 
To  demonstrate  the  robustness  of  fabryq  in  developing  appli¬ 
cations  for  use  with  highly  custom  BLE  devices,  we  present 
qfabryq,  a  custom  BLE  device  paired  with  a  JavaScript  API 
written  on  top  of  fabryq  that  make  some  of  the  most  use¬ 
ful  features  of  embedded  processors  such  as  analog  to  dig¬ 
ital  converters  (ADCs),  interrupts,  digital  input/output  pins 
(GPIO),  pulse  width  modulation  (PWM),  and  a  serial  periph¬ 
eral  interface  (SPI)  available  to  web  programmers  via  fab¬ 
ryq.  This  firmware  mirrors  the  programming  model  of  popu¬ 
lar  “maker”  platforms  such  as  Arduino,  but  offers  the  benefit 
that  applications  can  be  distributed  across  many  wearable  de¬ 
vices  in  many  locations.  In  order  to  both  validate  fabryq  and 
demonstrate  its  utility,  we  will  describe  the  devices  created 
by  students  using  qfabryq  during  a  hackathon. 


RELATED  WORK 

fabryq  relates  to  prior  work  in  ubicomp  prototyping  toolkits, 
research  on  working  with  sensor  data  on  mobile  phones,  ex¬ 
perience  logging,  and  “Internet  of  Things”  networking. 

Ubicomp  Prototyping 

HCI  research  has  contributed  systems  for  rapid  prototyping  of 
Ubicomp  devices  and  systems  [8,  9,  4,  18].  While  some  fo¬ 
cus  exclusively  on  self-contained  interactions,  others  such  as 
.NET  Gadgeteer  [18]  and  Shared  Phidgets  [15]  explicitly  of¬ 
fer  network  connectivity  to  create  Internet-connected  devices. 
However,  these  devices  tend  to  be  tethered  and  not  optimized 
for  power  consumption,  so  they  cannot  easily  be  deployed  in 
mobile  scenarios  outside  the  lab.  We  focus  on  sensing  sys¬ 
tems  that  are  easy  to  write  and  prototype  with,  yet  can  be 
given  to  users  without  supervision  and  deployed  in  real  world 
scenarios  for  weeks  to  months  at  a  time. 

Connecting  Sensors  to  Mobile  Phones 

A  number  of  projects  aim  to  make  it  easier  to  connect  external 
devices  and  sensors  to  smart  phones  and  use  them  in  applica¬ 
tions.  iStuffMobile  [2]  augments  existing  phones  with  new 
sensors  -  for  development  speed,  sensor  mapping  logic  runs 
on  a  nearby  desktop  computer,  limiting  deployment  options. 
Amarino  [12]  allows  designers  to  access  events  occurring  on 
a  mobile  phone  from  an  embedded  platform.  Hijack  [13] 
can  power  and  exchange  messages  with  an  embedded  mi¬ 
crocontroller  through  a  phone’s  audio  jack.  Open  Data  Kit 
Sensors  [6]  is  an  application  framework  that  introduces  ab¬ 
stractions  to  simplify  the  connection  of  multiple  sensors  with 
different  communication  channels  and  APIs  (e.g.,  wired  and 
Bluetooth)  to  a  single  mobile  device.  Dandelion  [14]  gener¬ 
ates  both  smart  phone  and  sensor  node  binaries  from  a  com¬ 
mon  source  and  then  uses  remote  method  invocation  to  call 
sensor  code  from  the  phone. 

In  contrast  to  these  projects,  fabryq  uses  the  phone  as  a  smart 
router  to  relay  commands  from  a  Web  server  to  BLE  devices. 
This  allows  developers  to  change  their  sensor  querying  code 
at  any  time  without  having  physical  access  to  the  phone,  and 
applications  can  span  multiple  phones,  fabryq  is  also  agnostic 
to  which  phone  is  connected  to  which  sensor — only  commu¬ 
nication  between  server  and  sensor  matters. 

Experience  Logging 

Experience  sampling  and  logging  tools  such  as  Momento  [5] 
and  MyExperience  [7]  aim  to  capture  a  user’s  daily  experi¬ 
ence  “in  the  wild”  outside  of  the  lab.  These  goals  are  aligned 
with  our  focus  of  creating  prototypes  that  can  be  deployed 
with  users  and  monitored  remotely  for  extended  periods  of 
time.  MyExperience,  for  example,  allows  capturing  of  sensor 
data  based  on  declarative  rules;  data  is  automatically  synced 
to  a  server.  The  architecture  supports  addition  of  external  sen¬ 
sors  (e.g.,  Bluetooth  devices)  by  writing  drivers  for  a  partic¬ 
ular  phone,  but  this  is  difficult.  The  principal  difference  is 
fabryq’s  focus  on  supporting  custom  peripheral  devices. 

loT  Networking 
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Connecting  resource-constrained  embedded  hardware  to  In¬ 
ternet  servers  is  also  a  concern  of  “Internet  of  Things”  re¬ 
searchers.  One  way  to  provide  IP  packet  support  to  low- 
energy  embedded  devices  is  through  IEEE802.15.4  networks 
using  “6L0WPAN”  (IPv6  over  Low  Power  Wireless  Personal 
Area  Networks  [1]).  Alternatively,  devices  such  as  the  XBee 
Internet  Gateway  marshall  traffic  between  a  local  area  net¬ 
work  and  the  Internet.  The  main  difference  to  much  of  this 
work  is  that  it  presupposes  additional  networking  infrastruc¬ 
ture  which  is  not  generally  available  yet.  We  instead  target 
ubiquitous  smart  phones  and  their  data  networks. 

Electriclmp  WiFi  modules  aim  to  lower  the  threshold  for  de¬ 
veloping  Internet-connected  appliances  [11].  Like  fabryq, 
Imp  uses  a  hosted  server  that  handles  many  lower-level  net¬ 
working  tasks.  However,  Imp  devices  require  direct  WiFi 
access — power  requirements  make  it  infeasible  to  use  them 
for  mobile,  wearable  deployments. 

MOTIVATING  APPLICATIONS 

To  inform  the  design  of  fabryq,  we  surveyed  the  emerging 
market  of  hardware  smartphone  “accessories.”  Fitness  track¬ 
ers  such  as  the  FitBit,  Misfit  Shine,  or  ActiveReplay’s  Trace 
as  well  as  devices  such  as  the  Automatic  vehicle  data  link  tend 
to  follow  a  similar  pattern:  they  use  MEMS  sensors  and  min¬ 
imal  display  on  device  and  they  a  smart  phone  to  display  the 
main  UI  to  the  user.  They  also  use  web  backends  to  store,  pro¬ 
cess,  or  share  data  e.g.,  to  allow  users  to  compete  on  daily  step 
counts.  Our  work  is  also  motivated  by  a  collaboration  with 
medical  researchers  at  a  local  medical  center  and  their  needs 
for  wearable  patient  monitoring  devices  (see  Figure  3).  These 
devices  generally  require  small  physical  size  and  weight  but 
battery  life  on  the  order  of  weeks  or  months  so  they  can  be 
given  to  patients  without  requiring  recharging  or  other  man¬ 
agement.  Researchers  want  to  send  patients  home  with  these 
devices  and  remotely  track  gathered  sensor  data  at  their  in¬ 
stitution.  Such  deployments  may  require  fabrication  of  a  few 
dozen  identical  devices.  Accordingly,  a  framework  should 
facilitate  deployment  of  prototype  code  to  multiple  users. 

Finally,  we  draw  inspiration  from  experiences  gathered  teach¬ 
ing  the  design  of  integrated  interactive  hardware/software  de¬ 
vices  at  our  institution.  While  teams  of  motivated  undergrad¬ 
uate  and  graduate  students  can  create  working  prototype  de¬ 
vices  such  as  the  ones  shown  in  Figure  4,  much  of  the  im¬ 
plementation  difficulty  lies  in  working  with  multiple  differ¬ 
ent  networking  technologies  and  protocols  simultaneously; 
managing  intermittent  wireless  connections;  and  doing  this  in 
multiple  different  programming  languages  on  different  plat¬ 
forms  (embedded,  mobile,  web)  with  different  conventions, 
data  encoding  schemes,  etc. 

Design  Guidelines 

Common  patterns  in  our  device  survey  (Figure  5)  yielded  the 
following  design  guidelines: 

Smartphone  as  proxy  A  modem  smartphone  is  the  one 
piece  of  infrastructure  that  can  be  assumed  to  be  present. 
Therefore,  leverage  the  smart  phone  as  a  proxy  from  the 
local,  body-area  network  to  the  Internet. 


Figure  3.  Three  motivating  wireless  medical  devices:  A)  A  retainer  that 
tracks  wearer  compliance  using  a  built-in  temperature  sensor.  B)  A  chest 
compression  brace  that  tracks  applied  pressure  over  time.  C)  A  water 
mug  that  tracks  liquid  consumption  throughout  the  day. 


Figure  4.  Example  devices  from  our  class:  A)  A  wireless  barrel  gauge 
for  distilleries  and  wineries;  barrel  readings  are  aggregated  online.  B) 
A  toy  to  support  literacy  education;  play  statistics  are  collected  on  the 
phone  and  online.  C)  A  car  dongle  that  streams  driving  telemetry  data 
to  the  phone  and  compares  driving  behavior  on  a  central  server. 
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Figure  5.  Features  of  some  motivating  examples,  fabryq  focuses  on  sup¬ 
porting  embedded  sensing,  relaying  data  through  a  phone,  and  aggre¬ 
gating  and  displaying  info  on  the  Web  (green  columns). 


Prototyping  “in  the  wild”  Enable  prototyping  of  wearables 
that  can  be  taken  outside  of  the  lab  and  that  can  run  for  at 
least  24  hours,  but  ideally  weeks  or  months. 

Multiple  devices  Facilitate  development  and  management  of 
multiple  identical  prototypes  that  can  be  distributed  to  a 
group  of  users  (e.g.,  patients  for  feasibility  studies) 

Display  Enable  developers  to  show  collected  data  and  other 
user  interfaces  both  on  the  web  and  on  a  phone. 

Abstract  networking  details  Shield  developer  from  net¬ 
work  connection  management  and  data  transfer  details. 

Lower  threshold,  high  ceiling  Enable  users  who  have  lim¬ 
ited  programming  experience  (e.g.,  clinical  researchers)  to 
write  simple  data  collection  scripts  in  a  single  language; 
enable  experts  to  create  new,  complex  devices. 

Conversely  we  chose  to  avoid  supporting  the  following  cases: 

No  low-latency,  high-throughput  apps  We  focus  on  work¬ 
ing  with  intermittently  read  sensor  data  where  milliseconds 
of  latency  are  not  important. 

No  offline  operation  without  a  cloud  server  We  target  pro¬ 
totype  deployment  where  a  designer/experimenter  is  still 
in  the  loop;  we  do  not  target  the  scenario  of  BLE  devices 
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talking  to  phone  applications  without  code  running  in  the 
cloud. 

FABRYQ  ARCHITECTURE 

fabryq’s  core  is  an  abstraction  of  the  Bluetooth  Low  Energy 
(BLE)  protocols.  We  first  briefly  introduce  some  BLE  ter¬ 
minology  necessary  for  explaining  the  architecture.  We  then 
introduce  a  scenario  that  demonstrates  how  a  developer  writes 
and  deploys  a  fabryq-enabled  application.  We  then  describe 
the  fabryq  implementation  that  enables  this  workflow. 

BLE  fundamentals 

BLE  is  a  wireless  protocol  for  communication  between  a  cen¬ 
tral  device  (i.e.,  a  mobile  phone)  and  one  or  more  periph¬ 
eral  devices  (i.e.,  wearables).  Peripheral  devices  expose  BLE 
characteristics  —  short,  named  pieces  of  information  (typi¬ 
cally  1-20  bytes)  similar  to  variables.  Central  devices  can  can 
perform  three  operations  on  characteristics:  GET,  SET,  and 
NOTIFY.  A  GET  signifies  that  the  BLE  central  device  would 
like  to  retrieve  the  contents  of  the  characteristic  from  the  BLE 
peripheral.  A  SET  means  that  the  BLE  central  would  like  to 
modify  the  contents  of  the  characteristic.  A  NOTIFY  signi¬ 
fies  that  if  the  value  of  the  characteristic  should  change  on  the 
peripheral,  the  central  would  like  to  be  notified  of  this. 

Operations  happen  at  a  set  connection  interval ,  a  precise  time 
window  when  the  central  and  peripheral  have  decided  to  com¬ 
municate.  Though  it  is  beyond  the  scope  of  this  work,  the 
connection  interval  is  critical  to  maintaining  deterministic 
power  consumption — a  longer  interval  means  less  data  can 
be  communicated  but  less  power  is  used.  By  adjusting  the  in¬ 
terval,  a  battery  life  of  greater  than  one  year  can  be  achieved 
from  a  coin  cell  battery:  one  of  the  hallmarks  of  BLE  periph¬ 
erals. 

The  set  of  characteristics  of  a  device  is  described  in  a  Generic 
ATTribute  profile  (GATT).  The  peripheral  device  is  also 
known  as  the  GATT  server;  the  central  device  as  the  GATT 
client.  Characteristics  are  identified  by  universally  unique 
identifiers  (UUIDs) — four  digit  UUIDs  are  reserved  by  the 
Bluetooth  Special  Interest  Group  (SIG)  for  common  use 
cases,  and  128-bit  UUIDs  are  used  for  custom,  developer  spe¬ 
cific  characteristics.  Characteristics  are  further  grouped  by 
belonging  to  services,  which  are  collections  of  characteristics. 
A  particular  BLE  peripheral  often  contains  multiple  services, 
for  example,  a  “device  identification  service”  (0x1 8  0 A)  and 
a  “heart  rate  service”  (0x1 8 0D)  would  be  typical  of  a  com¬ 
mercially  available  heart  rate  monitor.  Characteristics  and  the 
services  they  belong  to  make  up  the  “characteristic  tree.”  A 
more  detailed  description  of  BLE  can  be  found  in  [10,  3]. 

Scenario:  how  to  write  and  deploy  a  fabryq  app 

Developer  facing  fabryq:  defining  the  application  configuration 
fabryq  enables  application  developers  to  work  with  commer¬ 
cial  off-the-shelf  devices  (with  defined  behavior  exposed  in 
4-digit  UUIDs)  and  novel,  developer-defined  devices  (with 
custom  firmware  and  custom  characteristics  that  use  128-bit 
UUIDs).  We  now  present  the  workflow  for  writing  and  de¬ 
ploying  a  fabryq-enabled  web  application  in  either  case. 


Object 

Type 

Instance 

App 

App  Type 

App  Install 

BLE  Peripheral 

Device  Type 

Virtual  Device 

Table  1.  Types  and  instances  in  the  fabryq  application  configuration 
interface.  Instances  are  created  in  a  “user  portal”  whereas  types  are 
created  in  a  “developer  portal.”  Types  listed  in  italics  are  identified  by 
either  a  standard  (4-digit)  or  custom  (128-bit)  BLE  UUID.  Other  types 
and  all  instances  are  identified  by  fabryq-specific  identifiers. 

Application  developers  must  take  two  major  steps:  first,  they 
define  the  BLE  device  requirements  to  run  their  application 
using  the  fabryq  application  configuration  interface.  Second, 
they  then  write  application  code  (using  the  fabryq  JavaScript 
API)  that  references  this  hardware  configuration  profile.  For 
example,  a  hypothetical  HydrateForHeartHealth  (HFHH)  ap¬ 
plication  may  track  a  user’s  liquid  intake  over  the  course  of  a 
day  and  correlate  it  with  heart  rate  variability.  It  may  require 
information  about  liquid  level  in  a  smart  cup  (a  custom  de¬ 
vice  also  created  by  the  developer)  and  data  from  a  heart  rate 
monitor  (a  commercial  device). 

fabryq  application  configuration  requires  developers  to  oper¬ 
ate  at  a  level  of  abstraction  because  the  defined  application 
should  be  able  to  run  for  multiple  users  and  multiple  devices 
(and,  multiple  applications  may  need  to  use  data  from  the 
same  device).  In  our  running  example,  clinical  researchers 
may  want  to  give  smart  cups  and  heart  rate  monitors  to  two 
dozen  patients — each  patient’s  data  will  be  collected  by  an  in¬ 
stance  of  the  HFHH  application  that  communicates  with  par¬ 
ticular  hardware  devices.  In  other  words,  while  application 
developers  define  the  hardware  requirements  to  run  their  ap¬ 
plication  (e.g.,  the  application  requires  BLE  devices  that  ex¬ 
pose  heart  rate  and  temperature),  it  is  only  the  end  user  who 
will  associate  their  particular  hardware  device  with  the  appli¬ 
cation  (i.e.,  their  smart  cup  and  their  commercial  Heart  Rate 
monitor).  Therefore,  in  the  fabryq  architecture,  developers 
specify  abstract  application  types  that  require  abstract  device 
types.  This  is  done  in  the  fabryq  application  configuration 
interface  and  will  now  be  explained  in  more  detail. 

Our  HFHH  developer,  knowing  that  she  would  like  her  ap¬ 
plication  to  use  both  an  off-the-shelf  heart  rate  monitor  and 
a  custom  smart  cup  that  she  has  also  made,  begins  the  de¬ 
velopment  process  by  entering  the  information  for  her  fabryq 
application.  Identification  in  the  application  configuration  in¬ 
terface  is  performed  using  a  two-tiered  system  of  “types”  and 
’’instances”  which  are  listed  in  Table  1.  Specific  elements  of 
application  configuration  are  as  follows.  Device  types  are  a 
collection  of  service  types  and  characteristic  types  (the  char¬ 
acteristic  tree  discussed  previously,  but  abstracted  as  to  not 
imply  a  particular  physical  instance  of  a  device).  Analogous 
to  device  types,  application  types  are  containers  of  device 
types — they  define  the  peripheral  requirements  for  an  appli¬ 
cation.  These  relationships  are  depicted  in  Figure  6. 

With  these  definitions  in  mind,  our  HFHH  developer  enters 
the  heart  rate  monitor  into  the  fabryq  application  configu¬ 
ration  interface  as  in  Figure  7.  She  creates  a  new  device 
type  and  identifies  it  as  a  generic  branded  “Cheap  HR  mon¬ 
itor.”  Next,  she  links  the  heart  rate  service  type  and  heart 
rate  characteristic  types  (both  BLE  standards)  to  the  device 
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HR  Service 
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Device  Info  Service 
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fabryq  app.  config.  interface 
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(not  installations) 


SmartCup 
HR  Monitor 
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Figure  6.  Overview  of  fabryq  application  configuration.  Characteristic 
types  are  contained  inside  service  types,  which  are  contained  inside  de¬ 
vice  types.  Application  types  are  defined  by  a  list  of  device  types  they 
require.  Virtual  devices  are  real-world  realizations  of  device  types;  ap¬ 
plication  installs  require  one  virtual  device  for  every  device  type  listed 
for  its  application  type. 


type.  She  then  repeats  the  process  for  her  smart  cup,  this  time 
(not  shown)  first  defining  custom  service  and  characteristic 
types,  then  linking  it  to  her  smart  cup  device  type.  While 
these  custom  services  and  characteristics  depend  entirely  on 
the  firmware  running  on  the  smart  cup,  an  example  custom 
service  may  be  a  “water  consumption”  service  with  a  charac¬ 
teristic  of  “liters  drank  today.” 

She  now  proceeds  to  add  the  application  type,  named  HFHH. 
In  a  similar  interface  to  the  device  type  tree  (not  shown),  the 
application  type  is  defined  and  linked  to  device  types.  In  this 
case,  the  HFHH  application  type  is  linked  to  the  “Cheap  HR 
Monitor”  type  and  the  “Smart  Cup”  type.  The  application  is 
now  fully  configured  in  fabryq  and  our  developer  is  ready  to 
write  code  that  interacts  with  the  two  device  types  she  has 
required.  She  employs  the  fabryq  JavaScript  API  (details 
of  which  are  discussed  in  a  subsequent  section)  to  interact, 
through  fabryq,  with  the  server’s  virtual  representation  of  the 
required  peripherals  as  if  they  were  “always”  connected  to  the 
end  user’s  web  browser,  fabryq  will  queue  her  commands  and 
push  them  down  to  the  actual  devices  when  they  are  available. 


Figure  7.  fabryq  application  configuration  interface:  characteristic 
types,  service  types,  and  device  types  can  be  defined  and  linked  together. 
Here,  a  developer  defines  a  Heart  Rate  Monitor  device  type  (red)  which 
exposes  a  standard  Heart  Rate  service  (green)  and  characteristic  (blue), 
for  use  in  their  application.  Data  are  stored  in  a  simple  MySQL  backend. 
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Figure  8.  Screenshots  of  the  fabryq  web  portal,  (left)  the  user  indicates 
they  have  devices  of  type  “Cheap  HR  monitor”  and  “SmartCup”  by  cre¬ 
ating  virtual  device  of  those  types,  (right)  The  user  installs  the  HFHH 
app  and  associates  it  to  a  virtual  device. 

User  facing  fabryq:  unboxing  and  running  the  application 
A  user  of  a  fabryq-enabled  web  application  must  perform 
three  major  steps:  first,  they  must  install  the  “fabryq  mo¬ 
bile”  iOS  application  on  all  of  the  iOS  devices  they  desire 
to  use  to  “connect”  their  BLE  peripherals  to  fabryq.  This 
step  happens  once  per  iOS  device,  regardless  of  the  number 
of  fabryq-enabled  applications  being  run.  Second,  they  must 
indicate  possession  of  their  peripherals  and  “install”  the  web 
applications  they  desire:  both  of  these  actions  take  place  on  a 
website  referred  to  as  the  “fabryq  web  portal.”  Finally,  they 
must  “run”  the  web  application  by  navigating  to  the  devel¬ 
oper’s  web  application  URL.  Upon  the  first  run  of  the  web 
application,  all  iOS  devices  that  have  never  connected  before 
to  the  peripheral  of  interest  will  have  to  connect  with  and  reg¬ 
ister  the  id  of  the  target  peripheral,  through  user  interaction 
in  the  fabryq  mobile  application.  Steps  two  and  three  of  the 
above  summarized  process  are  now  explained  in  more  detail. 

Following  our  example  scenario,  a  user  has  received  the  de¬ 
veloper’s  smart  cup  and  a  generic  heart  rate  monitor,  and 
would  like  to  use  the  developer’s  application  for  the  first  time. 
First,  the  user  will  “install”  the  HFHH  application  on  the  fab¬ 
ryq  web  portal  (Figure  8).  Next,  the  user  will  indicate  that 
he  or  she  owns  the  peripherals  by  adding  them  in  the  virtual 
devices  tab.  Then,  they  will  associate  those  devices  with  the 
new  application  install,  indicating  to  fabryq  that  when  they 
“run”  this  instance  of  the  HFHH  application,  they  would  like 
it  to  interact  with  those  two  exact  peripherals. 

Next,  assuming  fabryq  mobile  is  already  installed  on  the 
user’s  iOS  device(s),  the  user  points  his  or  her  web  browser1 
to  the  developer’s  application.  The  very  first  time  the  appli¬ 
cation  is  run,  an  identification  request  is  made  to  the  new  vir¬ 
tual  device  created  when  the  user  added  their  new  device  on 
the  web  portal.  The  user’s  fabryq  mobile  application,  see¬ 
ing  this  request  and  knowing  that  they  have  never  physically 

1  In  our  current  implementation,  the  web  browser  must  not  be  on  the 
same  phone  the  one  with  fabryq  mobile  installed,  because  fabryq 
mobile  runs  in  the  foreground.  This  is  addressed  in  the  limitations 
section. 
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Figure  9.  Possible  application  configurations  enabled  by  Fabryq:  A) 
single  user,  single  device.  B)  A  user’s  peripheral  accesses  fabryq  through 
more  than  one  mobile  device  in  a  “roaming”  pattern  C)  Users  who  agree 
to  jointly  run  an  application  can  also  act  as  ’’data  mules”  and  pick  up 
data  from  environmental  sensors  whenever  they  walk  by  such  a  sensor. 


connected  to  this  virtual  device  before,  will  initiate  a  BLE 
scan  and  query  the  user  to  identify  which  physical  peripheral 
corresponds  to  this  virtual  device.  For  every  instance  of  the 
fabryq  mobile  app,  once  the  user  selects  the  peripheral,  sub¬ 
sequent  requests  from  fabryq  will  pass  through  directly  to  the 
peripheral  without  user  intervention.  The  details  of  this  im¬ 
plementation  are  depicted  in  Figure  10  and  discussed  in  more 
detail  in  a  subsequent  section. 

In  the  simplest  case,  one  application  requires  one  peripheral 
and  the  user  has  one  (or  more)  iOS  devices  (each  running 
fabryq  mobile)  that  allow  data  to  flow  from  application  to 
peripheral  (Figure  9A).  One  application  may  also  allow  the 
user  to  “roam”  with  their  BFE  peripheral,  periodically  com¬ 
ing  into  contact  with  one  of  their  multiple  iOS  devices,  as  in 
Figure  9B.  Finally,  users  may  opt  to  “share”  their  iOS  de¬ 
vice’s  BFE  radio  with  other  users.  In  this  configuration,  other 
users  would  be  able  to  connect  their  peripherals  to  fabryq  us¬ 
ing  iOS  devices  that  are  not  in  their  possession.  As  a  simple 
example,  a  cyclist’s  heart  rate  monitor  could  connect  to  his 
heart  rate  application  while  he  cycles  without  an  iOS  device, 
provided  he  comes  in  contact  with  other  user’s  devices.  De¬ 
picted  in  Figure  9C,  this  “crowd  sourced  BFE  internet  access” 
has  been  implemented  in  specific  consumer  applications  such 
as  Tile  2 . 

Having  presented  an  overview  of  the  workflow  to  write  and 
run  a  fabryq-enabled  web  application,  we  will  now  discuss 
the  specifics  of  the  fabryq  implementation. 

fabryq  Implementation 

The  function  of  fabryq  is  analogous  to  that  of  an  IP  router: 
fabryq  commands  (GET,  SET,  NOTIFY)  are  requested  of 
the  server  by  the  JavaScript  application  code  running  in 
the  browser  and  “routed”  to  the  appropriate  BFE  peripheral 
through  the  various  fabryq  mobile  apps  (installed  on  iOS  de¬ 
vices),  based  on  which  user  is  currently  running  the  applica¬ 
tion  and  what  virtual  devices  they  have  associated  with  that 
application  install.  Beyond  routing  BFE  commands,  fabryq 
also  has  the  functionality  of  routing  a  user  interface  to  a  mo¬ 
bile  device  connected  to  a  BFE  peripheral.  The  main  chal¬ 
lenge  in  implementing  such  a  router  is  overcoming  three  pri¬ 
mary  limitations  of  the  bluetooth  low-energy  protocol: 


2http://www.thetileapp.com 


1 .  Inconsistent  identification  of  a  user’s  peripheral  devices 

across  all  of  their  mobile  devices  (e.g.,  using  one  heart  rate 
monitor  with  several  phones  and/or  tablets).  In  the  case 
of  iOS  (the  only  platform  that  we  have  so  far  used  to  im¬ 
plement  the  fabryq  mobile  app),  a  unique  identifier  is  gen¬ 
erated  for  every  bluetooth  peripheral  for  every  iOS  appli¬ 
cation. ,  that  is  to  say,  three  applications  connecting  to  the 
same  peripheral  (even  on  the  same  device)  will  have  a  dif¬ 
ferent  unique  identifier  for  that  peripheral.  This  behavior 
allows  some  high  security  applications  like  car  keys  and 
bank  cards  but  presents  a  major  difficulty  in  managing  pe¬ 
ripherals  across  applications  and  devices. 

2.  Poor  correlation  of  command  requests  with  responses. 
In  all  current  BFE  central  implementations,  callbacks  from 
GET,  SET,  and  NOTIFY  commands  are  shared  and  can  re¬ 
turn  in  a  different  order  than  their  initiating  calls.  While 
these  callbacks  do  contain  the  characteristic  UUID  that 
is  being  queried,  if  one  is  repeatedly  calling  GET,  SET, 
and/or  NOTIFY  on  a  single  characteristic,  maintenance  of 
proper  callback  order  becomes  a  formidable  task  for  the 
developer  that  must  be  reimplemented  in  a  highly  custom, 
characteristic- specific  manner  for  each  application. 

3.  Redundant  calls  to  rediscover  characteristics.  In  all  cur¬ 
rent  BFE  central  implementations,  the  characteristic  tree 
must  be  traversed  over  the  wireless  link,  down  to  the  char¬ 
acteristics  of  interest  on  each  connection.  That  is  to  say,  on 
each  connection,  even  if  a  characteristic  is  known  to  exist 
in  a  particular  service,  the  service  and  characteristic  must 
first  be  “discovered”  over  the  wireless  link  prior  to  exe¬ 
cuting  one  of  the  three  BFE  commands.  Ideally,  a  priori 
knowledge  of  the  characteristic  tree  is  known  by  the  mobile 
application  to  ensure  minimum  traversal  of  the  tree,  which 
readily  leads  to  non-portable  “hard  coding”  of  character¬ 
istics.  The  alternative  is  power  inefficient,  over- traversal 
of  the  tree.  We  address  this  BFE  limitation  in  fabryq  by 
downloading  the  tree  from  the  application  configuration, 
ensuring  consistent,  minimum  traversal. 

The  fabryq  mobile  application  and  its  JavaScript  API  have 

been  implemented  specifically  to  overcome  these  limitations. 


fabryq  mobile  Implementation 

The  primary  function  of  the  fabryq  mobile  application  is  to 
execute  commands  (i.e.  GET,  SET,  NOTIFY)  requested  of 
characteristics  of  virtual  devices.  Because  of  BFE’s  periph¬ 
eral  identification  challenges,  the  fabryq  mobile  app  must 
know  which  physical  device  corresponds  to  which  virtual  de¬ 
vice  for  every  mobile  device. 

To  overcome  this  limitation  we  have  devised  the  following 
control  flow,  shown  in  Figure  10,  resulting  in  minimal  ex¬ 
tra  user  interaction  with  no  additional  developer  code.  Com¬ 
mands  (i.e.  GET,  SET,  NOTIFY)  to  be  performed  on  virtual 
devices  are  placed  in  a  server- stored  “command  log”  by  calls 
to  the  fabryq  javascript  API  (detailed  in  the  next  section).  If 
commands  are  found  for  the  user’s  virtual  devices,  the  fabryq 
mobile  application  first  determines  if  it  has  an  OS-specific 
BFE-identifier  for  that  virtual  device.  If  it  does,  the  action  is 
performed  and  the  result  returned  to  the  command  log.  If  not, 
and  there  are  nearby,  unknown  peripherals  that  are  exposing 
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Figure  10.  Control  flow  for  fabryq  mobile.  If  commands  (i.e.  GET, 
SET,  NOTIFY)  are  found  for  the  logged-in  user’s  virtual  devices,  fab¬ 
ryq  mobile  first  determines  if  it  has  an  OS-specific  BLE-identifier  for 
that  virtual  device.  If  such  a  “link”  between  OS-specific  identifier  and 
virtual  device  exists,  the  action  is  performed  and  the  result  returned  to 
the  database.  If  not,  and  there  are  nearby,  unknown  peripherals  that  are 
exposing  the  characteristic  type  to  be  acted  upon  by  the  task,  the  user 
will  be  queried  with  the  “friendly  name”  of  the  virtual  device  obtained 
from  the  application  configuration,  and  a  list  of  nearby  BLE  peripher¬ 
als.  If  the  user  indicates  one  of  these  peripherals  is  a  match,  it  will  be 
stored  permanently  and  the  action  performed. 

the  service  type  needed  by  the  task,  the  user  will  be  queried 
with  the  “friendly  name”  of  the  virtual  device  obtained  from 
the  application  configuration,  and  a  list  of  nearby  BLE  pe¬ 
ripherals.  If  the  user  indicates  one  of  these  peripherals  is  a 
match,  it  will  be  stored  permanently  (on  the  same  SQL  server 
as  the  command  log)  and  the  action  will  be  performed. 

By  decoupling  the  act  of  requesting  GET,  SET,  and  NOTIFY 
commands  from  the  act  of  performing  them,  we  also  address 
the  other  two  BLE-specific  limitations:  excess  traversal  of  the 
characteristic  tree  and  ordering  of  commands.  The  former  is 
prevented  because  the  for  a  given  device  type  in  the  fabryq  ap¬ 
plication  configuration,  the  entire  characteristic  tree  is  known 
prior  to  the  iOS  device  establishing  a  connection,  without  any 
“hard  coding”  of  the  UUIDs.  Thus,  upon  connecting  to  a  de¬ 
vice,  the  bare  minimum  traversal  of  the  characteristic  tree  au¬ 
tomatically  takes  place,  and  the  characteristics  are  available 
for  direct  query. 

The  latter  is  addressed  by  the  nature  of  the  design:  the  com¬ 
mand  log  itself  is  in  execution- order.  Each  time  fabryq  mo¬ 
bile  is  to  return  a  result  from  an  action,  it  only  has  one  place 
to  do  it:  in  the  correct  spot  in  the  log.  As  mentioned  ear¬ 
lier,  a  limitation  to  BLE  API  callbacks  from  GET,  SET,  and 
NOTIFY  commands  on  mobile  phones  is  that  they  happen 
in  an  undetermined  order  and  are  often  fixed  to  be  the  same 
callback  function.  Reconciliation  of  these  callbacks  with  the 
appropriate  row  in  the  log  table  represented  both  the  most 
formidable  challenge  and  greatest  benefit  in  developing  fab¬ 
ryq,  and  in  fact  is  a  defining  feature  of  the  JavaScript  API. 

Additional  fabryq  mobile  command:  SHOWURL 
In  some  instances,  the  developer  would  like  to  interact  with 
the  user  on  the  fabryq  mobile  application  directly  as  opposed 
to  the  web  browser.  For  this  purpose,  we  created  a  fourth  fab¬ 


ryq  command  without  a  BLE  counterpart:  SHOWURL.  Like 
the  other  commands,  SHOWURL  requires  that  one  of  the  user’s 
fabryq  mobile  applications  be  connected  to  the  particular  pe¬ 
ripheral.  However,  instead  of  passing  a  command  over  BLE, 
it  shows  a  URL  on  the  fabryq  mobile  application  itself:  we 
term  this  UI  pushdown.  In  this  way,  peripheral- specific  UI 
can  appear  on  the  mobile  device  hosting  it.  Since  SHOWURL 
is  simply  opening  a  web  page,  the  full  complement  of  fabryq 
JavaScript  API  calls  are  also  available. 

Implementation  of  fabryq  javscript  API 
We  have  implemented  a  JavaScript  API  to  enqueue  and  de¬ 
queue  commands  and  poll  their  results.  These  commands  are 
intended  for  BLE  peripherals  but  originate  on  the  cloud:  our 
peripheral  proxy  model.  Each  GET,  SET,  or  NOTIFY  has 
an  explicitly  defined  callback  that  is  passed  to  the  originating 
JavaScript  function  call  (and  per  common  JavaScript  coding 
practice  can  be  defined  in-line).  A  demonstrative  use-case  for 
the  API  is  as  follows. 

Our  example  developer  would  like  to  access  the  heart  rate 
characteristic  of  an  off-the-shelf  BLE  heart  rate  monitor  for 
part  of  her  HFHH  application.  Having  already  entered  in  the 
application  configuration  as  described  earlier,  she  begins  to 
write  JavaScript  code.  She  first  obtains  the  fabryq  applica¬ 
tion  profile  object  using  an  AJAX  query.  The  fabryq  appli¬ 
cation  object  contains  a  list  of  all  virtual  devices  accessible 
to  the  application,  indexed  by  device  type.  Recall  that  this 
was  a  major  design  requirement:  the  developer  does  not  need 
knowledge  of  particular,  physical  devices,  but  only  their  type. 
In  this  example,  she  would  like  her  application  to  display  the 
current  user’s  heart  rate  on  the  screen  using  a  GET  command. 
Using  fabryq’s  JavaScript  API,  this  is  one  function  call  with 
embedded  callback  lambdas: 

add_get_action ( 

f abryq_ob ject [_DEVICE_TYPE ] , 

_HR_SERVICE , 

_HR_CHARACTERISTIC, 

_POLL_INTERVAL, 

_TIMEOUT, 

function  onCompleted (action) 

{ 

if (action . result==' null' )  { 

//update  the  screen  to  indicate  the 
//heart  rate  monitor  could  not  be  located 

} 

else  { 

//update  the  screen  with 
//action . result  (the  heart  rate) 

} 

}, 

function  onQueued (action)  {}, 
install_id 

)  ; 

The  _DEVICE_TYPE,  _HR_SERVICE,  and  the 
_HR_CHARACTERI  STIC  constants  are  already  known 
by  the  developer  as  she  recently  entered  them  into  the  fabryq 
application  configuration  interface.  .POLL .INTERVAL 
defines  how  often  and  .POLL .TIME OUT  defines  how  long 
the  command  log  will  be  polled  by  the  browser  for  the  result 
of  the  action.  A  timeout  indicates  that  the  peripheral  could 
not  be  found  by  any  of  the  user’s  fabryq  mobile  applications. 
The  onCompleted  callback  occurs  after  the  command  has 
been  successfully  performed  or  timed  out.  The  onQueued 
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Figure  11.  Demonstrative  fabryq  application  showing  the  user’s  heart 
rate  obtained  from  an  off-the-shelf  BLE  heart  rate  monitor  and  auto¬ 
matically  plotted  on  the  currently  connected  fabryq  mobile  application. 


occurs  after  the  command  has  been  placed  in  the  command 
log — this  is  useful  in  cases  where  a  number  of  commands 
must  be  executed  in  a  particular  order,  but  subsequent  com¬ 
mands  do  not  depend  on  the  results  of  preceding  commands, 
thus  they  can  be  immediately  queued.  The  install _id 
is  populated  when  the  user  logs  into  fabryq  and  runs  the 
application.  SET  and  NOTIFY  commands  are  similarly 
implemented  and  not  discussed  here. 

The  principle  limitation  of  the  JavaScript  API  is  the  require¬ 
ment  to  poll  the  command  log  to  discover  the  status  of  an 
action.  This  is  a  limitation  of  our  command  log  implemen¬ 
tation:  a  SQL  table  with  simple  REST  interface.  Trading  off 
simplicity  and  portability  for  latency,  future  implementations 
of  the  command  log  interface  could  utilize  WebSockets  or 
other  push  notification  schemes  to  allow  for  instant  callbacks 
to  JavaScript  as  soon  as  fabryq  mobile  has  interacted  with  the 
BLE  peripheral  and  updated  the  log. 

The  core  fabryq  implementation  was  written  in  about  4500 
lines  of  code  split  across  iOS  (fabryq  mobile);  PHP  and  SQL 
(fabryq  server)  and  Javascript  (fabryq  API). The  heterogeneity 
of  the  codebase  exemplifies  the  complexity  of  development 
that  fabryq  seeks  to  overcome. 

EXAMPLE  APPLICATIONS 

We  have  created  several  example  applications  to  demonstrate 
working  with  both  off-the-shelf  and  custom  peripherals. 

Example  with  off-the-shelf  BLE  device 

As  a  demonstrative  example,  we  created  a  simple  fabryq  ap¬ 
plication  that  can  plot  the  heart  rate  of  a  user  using  any  off- 
the-shelf  heart  rate  monitor  that  exposes  the  standard  BLE 
heart  rate  service  in  real  time.  In  addition  to  showing  the 
heart  rate  on  the  user’s  web  browser,  the  application  uses  the 
SHOWURL  fabryq  command  to  also  display  the  plot  on  the 
fabryq  mobile  application  currently  communicating  with  the 
heart  rate  monitor  (Figure  11).  The  completion  of  the  first 
functional  prototype  of  this  example  application  took  under 
three  hours,  the  majority  of  which  was  spent  on  the  construc¬ 
tion  of  the  visualization.  Conversely,  obtaining  the  heart  rate 
data  in  fabryq  required  only  two  function  calls,  one  to  start 
collecting  the  heart  rate  data  and  a  second  to  query  the  server 
for  the  history  of  the  user’s  heart  rate. 

End-to-end  use  case:  qfabryq 


Embedded  Smart  Phone  Web  Server  Web  Client 


Bluetooth  HTTP  over 

Low  WiFi  /  3G 

Energy 


I  I  Application  I  I  Fabryq  I  I  p  Fabryq  I  I  Existing  network 

dev’s  code  framework  framework  stacks/devices 

Figure  12.  qfabryq  offers  direct  access  to  embedded  peripheral  pins  in 
a  manner  similar  to  the  popular  Arduino  platform.  It  was  implemented 
using  Fabryq  and  shows  the  expressivity  of  the  framework.  It  comprises 
a  BLE  firmware  and  a  JavaScript  library  written  using  the  Fabryq  JS 
API. 


fabryq  JavaScript  API 

Function 

Description 

add get action 

Request  a  BLE  characteristic 

add set action 

Set  the  value  of  a  BLE  characteristic 

add notify action 

Receive  notification  of  a  changed  BLE  char. 

add showurl action 

Show  a  URL  on  the  connected  fabryq  mobile  app. 

jafabryq  JavaScript  API 

Function 

Description 

DigitalRead 

Read  a  pin’s  binary  value 

DigitalWrite 

Set  a  pin’s  output  voltage  to  low  or  high 

PinMode 

Set  a  pin  to  input  (w/  pullup)  or  output 

AnalogRead 

Read  a  pin’s  input  voltage  using  an  ADC 

AnalogWrite 

Set  a  pin’s  output  voltage  using  PWM 

AttachServo 

Enable  servomotor  control  on  a  pin 

ServoWrite 

Set  a  pin’s  servo  to  a  particular  location 

Attachlnterrupt 

Attach  a  JS  function  to  a  pin  interrupt 

SPIbegin 

Enable/configure  the  SPI  on  qfabryq 

SPItransfer 

Perform  full-duplex  SPI  communication 

Table  2.  Function  list  for  the  microfabryq  JavaScript  API  (top)  and  the 
Lifabryq  JavaScript  API  (bottom). 


To  demonstrate  fabryq’ s  ability  to  simplify  communication 
with  novel  BLE  devices,  we  created  a  customized  BLE  de¬ 
vice  with  functionality  resembling  that  of  an  Arduino  [16]. 
qfabryq,  shown  in  Figure  13,  is  a  breadboard-able  bluetooth 
system-on-chip  based  on  the  BlueGiga  BLE113  module.  We 
developed  custom  firmware  that  allows  Arduino-like  com¬ 
mands  to  be  used  over  BLE.  For  example,  there  is  a  custom 
BLE  characteristic  that  controls  the  output  of  all  GPIO  pins 
(high  or  low)  and  another  that  controls  the  pin  direction  (input 
or  output).  Using  only  the  fabryq  JavaScript  API  and  j Query, 
we  then  created  the  qfabryq  JavaScript  API  which  essentially 
maps  Arduino  commands  to  JavaScript  functions,  executing 
them  over  fabryq  and  returning  their  result  to  the  browser. 
A  list  of  these  qfabryq  API  functions,  along  with  the  fabryq 
JavaScript  API  functions,  is  in  Table  2. 

Custom  Devices 

As  a  preliminary  test  of  fabryq  and  qfabryq,  the  authors  con¬ 
structed  multiple  prototype  devices.  Among  them  was  a  se¬ 
curity  device  built  using  a  Pyroelectric  Infrared  (PIR)  sensor 
and  an  accelerometer  with  a  SPI  interface.  When  the  corre¬ 
sponding  script  is  run  in  a  web  browser,  it  sends  commands 
to  the  device  to  test  and  initialize  the  accelerometer,  set  an  ac¬ 
celeration  threshold  via  an  SPI  command,  and  set  interrupts 
on  the  interrupt  pin  of  the  accelerometer  and  the  output  of 
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Figure  13.  |jfabryq  breadboard  provided  to  participants  of  the 
hackathon.  The  board  contains  a  BlueGiga  BLE113  breakout  board, 
a  microUSB  battery  charger,  a  LiPo  battery  and  a  power  switch.  The 
rest  of  the  board  is  empty  for  prototypign. 

the  PIR  sensor.  Running  this  initialization  from  cloud  to  de¬ 
vice  takes  roughly  15  seconds  with  some  variability  due  to 
network  and  server  latency.  Whenever  the  sensors  are  trig¬ 
gered  by  a  person  walking  by  or  moving  the  pfabryq  board, 
the  board  pushes  an  update  to  the  fabryq  server,  where  it  is 
polled  by  the  web  application.  When  the  web  application  re¬ 
ceives  an  interrupt  message,  it  flashes  a  red  screen.  Latency 
from  activation  to  browser  display  is  about  3  seconds. 

User  Experiences  with  \xfabryq 

In  order  to  evaluate  and  demonstrate  fabryq’ s  ability  to  con¬ 
nect  to  and  transmit  data  from  a  number  of  peripherals,  we 
held  a  7-hour  pfabryq  hackathon.  Attendees  were  expected 
to  leverage  prior  Arduino  experience  to  create  novel  BLE  de¬ 
vices.  Attendees  were  of  various  engineering  backgrounds, 
namely,  Bio-,  Electrical,  and  Mechanical  Engineeering  as 
well  as  Computer  Science.  Twelve  students  in  four  groups 
were  provided  with  a  breadboard  that  contained  a  BLE  mod¬ 
ule  pre-loaded  with  the  pfabryq  firmware  (see  Figure  13). 
An  ample  supply  of  electronics  and  mechanical  prototyp¬ 
ing  equipment  was  made  available.  All  groups  success¬ 
fully  downloaded  and  ran  the  GPIO  demo  and  the  majority 
collected  sensor  readings  from  a  pfabryq  board  on  a  web 
server,  all  through  two  fabryq  mobile  applications  placed  in 
the  room.  Two  groups  went  beyond  small  examples  and 
built  their  own  custom  devices.  At  the  conclusion  of  the 
hackathon,  two  groups  remained  and  produced  the  following 
devices,  seen  in  Figure  14. 

Heart  Rate  Monitor:  Students  connected  an  off-the-shelf 
maker-focused  photo  plethysmography  sensor3  to  an  Arduino 
using  the  manufacturer-provided  library  to  determine  heart 
rate.  As  a  simple  way  to  bridge  the  5V  Arduino  and  3.3V 
pfabryq  board,  the  Arduino  converted  the  heart  rate  into  an 
analog  voltage  using  PWM  and  an  RC  filter.  This  voltage 
was  fed  into  an  A/D  pin  on  the  pfabryq  board,  where  it  was 
converted  to  a  digital  value  and  sent  to  the  browser  through 
fabryq.  Once  on  the  web,  the  analog  voltage  was  converted, 
in  JavaScript,  to  heart  rate  and  displayed  in  a  webpage. 

Tic  Tac  Toe:  Students  placed  a  grid  of  push-push,  on-off 
switches  and  associated  wiring  on  two  breadboards  and  con¬ 
nected  this  to  the  pfabryq  board  via  GPIO  pins.  The  on-off 

3http://pulsesensor.myshopify.com/ 


Figure  14.  (left)  Heart  rate  sensor  managed  by  an  Arduino,  which  is  con¬ 
nected  to  a  pfabryq  board,  (right)  pfabryq  breadboard  wired  to  several 
pushbutton  switches  acting  as  an  input  device. 


state  of  each  switch  was  pushed  to  the  web  browser  using  fab¬ 
ryq,  allowing  for  a  tic-tac-toe  board  on  the  web  that  could  be 
modified  using  the  physical  switches. 

Qualitative  feedback 

The  participants  appreciated  pfabryq’ s  ability  to  simplify 
what  would  otherwise  be  a  complex  networking  task.  Instead 
of  writing  code  for  an  embedded  device,  a  mobile  app,  and 
a  server,  participants  were  able  to  write  functioning  applica¬ 
tions  using  only  JavaScript  in  the  browser.  One  participant 
remarked,  “It’s  really,  really  easy  to  use,  especially  compared 
to  the  complexity  of  what  it  accomplishes.  I  think  the  current 
API  and  the  general  spirit  of  the  language’s  structure  makes 
it  really  intuitive  to  use.” 

Participants  spent  most  of  their  time  designing  and  debugging 
the  web  user  interfaces  of  their  devices.  Because  few  were  ex¬ 
pert  web  developers,  the  final  complexity  of  their  prototypes 
was  limited.  Nonetheless,  we  are  encouraged  by  the  results 
of  the  hackathon.  Although  the  groups  faced  technical  chal¬ 
lenges  in  interfacing,  web  design,  and  debugging,  they  were 
all  successful  at  communicating  with  the  pfabryq  boards.  Ad¬ 
ditionally,  when  asked,  “On  a  scale  of  1  to  5  how  likely  would 
you  be  to  use  fabryq  in  your  next  project?”  (where  5  was  very 
likely),  the  participants  responses  were  positive  (p  =  3.6). 

The  largest  challenges  that  the  participants  faced  involved  un¬ 
derstanding  the  status  and  failure  situations  of  the  back  end 
infrastructure.  This  suggests  that  exposing  more  fine-grained 
system  status  when  errors  occur  is  an  important  usability  con¬ 
sideration  for  future  versions  of  the  framework. 

LIMITATIONS 

fabryq  has  some  limitations  inherent  in  its  architecture  as  well 
as  shortcomings  in  the  current  implementation. 

Design  Limitations 

Fundamentally,  fabryq-enabled  applications  require  complete 
a  priori  knowledge  of  all  peripheral  types  prior  to  writing 
and/or  running  an  application.  This  was  explicitly  chosen  for 
robustness  in  connectivity  across  multiple  mobile  devices  and 
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scalability  of  applications  to  many  users  and  many  peripher¬ 
als.  There  exist  a  subset  of  applications  where  the  peripherals 
are  not  known,  for  example,  an  application  specifically  de¬ 
signed  to  discover  any  nearby  peripheral,  or  applications  that 
interact  with  beacons  that  change  their  identifiers  for  security 
reasons.  Such  applciations  are  not  supported. 

Implementation  Limitations 

The  current  fabryq  mobile  application  runs  only  on  iOS,  and 
only  in  the  foreground.  On  iOS,  there  are  stringent  require¬ 
ments  placed  on  background  applications,  such  as  timing  lim¬ 
itations.  None  of  these  requirements  should  fundamentally 
limit  fabryq’ s  current  functionality,  but  we  have  not  yet  im¬ 
plemented  a  background  mode. 

An  additional  limitation  is  poorly-defined  command  latency. 
This  is  not  a  fundamental  limitation;  if  the  application  con¬ 
figuration  and  command  log  were  located  on  the  mobile  de¬ 
vice,  the  command  latency  could  be  readily  defined.  Instead, 
our  current  implementation  relies  on  polling  to  A)  retrieve 
command  logs  for  fabryq  mobile  and  B)  retrieve  results  of 
these  commands  by  the  JavaScript  API.  In  future  implemen¬ 
tations,  both  of  these  polling  mechanisms,  which  take  place 
over  REST-ful  interfaces,  could  be  replaced  by  TCP/IP  socket 
schemes  such  as  WebSockets. 

Finally,  in  programming  fabryq-enabled  apps,  the  developer 
must  currently  edit  the  application  configuration  in  a  browser 
and  write  code  in  a  local  text  editor.  Testing  this  code  re¬ 
quires  opening  the  application  in  another  browser  window 
and  having  an  iOS  device  running  fabryq  mobile  physically 
near  the  peripheral  and  presumably  the  developer.  This  yields 
five  points  of  interaction  (two  browser  windows,  a  text  editor, 
fabryq  mobile,  and  the  peripheral)  for  the  developer  which 
can  become  a  challenge  in  and  of  itself,  slowing  down  the  de¬ 
velopment  cycle.  In  future  versions  of  fabryq,  some  of  these 
points  of  interaction  can  be  reduced  or  eliminated,  e.g.,  by 
providing  an  integrated  workbench  that  unifies  writing,  con¬ 
figuring  and  running  applications,  and  by  adding  device  sim¬ 
ulation  capabilities  (e.g.,  through  trace  playback  [17]). 

CONCLUSION  AND  FUTURE  WORK 

This  paper  presented  fabryq,  a  platform  for  rapidly  writing 
and  deploying  MPC  applications  that  use  smart  phones  as 
proxies  to  control  wearable  devices  from  the  Web.  The  de¬ 
velopment  of  fabryq  was  guided  by  a  survey  of  commercial 
devices,  medical  wearable  devices,  and  student  projects.  Two 
main  techniques  of  fabryq  are  the  protocol  proxy  model  of  ex¬ 
ecuting  BLE  protocol  calls  from  the  Web;  and  UI pushdown 
to  push  interfaces  from  the  Web  to  a  phone.  Future  work  on 
fabryq  will  focus  on  also  making  the  firmware  layer  config¬ 
urable  or  updatable  from  the  Web.  Just  as  characteristics  and 
services  have  been  abstracted  into  a  virtual  device  and  are 
available  any  time,  future  versions  of  fabryq  will  similarly 
absorb  the  firmware  into  the  virtual  device  as  part  of  a  single 
application  that  runs  on  phone,  cloud,  and  peripheral.  Fu¬ 
ture  fabryq  applications  will  have  a  “complete  picture”  of  the 
tasks  to  be  executed  on  the  peripheral,  on  the  phone,  and  on 
the  cloud.  With  this  picture,  individual  tasks  can  be  parceled 
out  to  the  appropriate  layers,  depending  on  available  network 


infrastructure,  available  hardware  infrastructure,  and  the  na¬ 
ture  of  the  tasks  requested. 
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